Method and Arrangement for Handling Client Data

ABSTRACT

A method and arrangement for authorizing an initially unauthorized watching client to receive client data of an observed client from a client data server. The watching client sends an expanded request for client data to the server. The expanded request contains additional information such as a text string, a picture, or a video/audio clip. The server extracts the additional information and sends it to the observed client. The observed client can then decide whether to authorize the watching client to receive the observed client&#39;s data based on the additional information.

TECHNICAL FIELD

The present invention relates generally to a method and arrangement forhandling client data of an observed client by means of a client dataserver. In particular, the present invention can be used to provideinformation from a watching client initially not authorised to receiveclient data, when requesting or subscribing for client data of theobserved client.

BACKGROUND

With the emergence of 3G mobile telephony, new packet-basedcommunication technologies using IP (Internet Protocol) have beendeveloped to support wireless communication of multimedia. For example,communication protocols in GPRS (General Packet Radio Service) and WCDMA(Wideband Code Division Multiple Access) support packet-switchedmultimedia services, as well as traditional circuit-switched voicecalls.

A network architecture called “IP Multimedia Subsystem” (IMS) has beendeveloped by the 3^(rd) Generation Partnership Project (3GPP) as aplatform for handling multimedia services and sessions in the packetdomain, based on IP transport. Thus, an IMS network can be used toinitiate and control multimedia sessions for any IP enabled terminalsbeing connected to any type of access networks. A signalling protocolcalled “SIP” (Session Initiation Protocol, according to the standardIETF RFC 3261) is typically used for handling sessions in IMS networks.A “SIP-enabled” terminal can thus use this standard to initiate andterminate multimedia communications by means of its home IMS network.

FIG. 1 is a simplified schematic illustration of a basic networkstructure for providing multimedia services by means of an IMS network100 for a client using a terminal A. In this example, terminal A is amobile terminal connected to a radio access network 102 and communicatesin a multimedia session with another terminal B, even though IMS can beused for fixed terminals as well. Alternatively, terminal A maycommunicate with a content server or the like, e.g. for downloading somemultimedia content therefrom. An IMS terminal is often generallyreferred to as “User Equipment (UE)”.

The access network 102 is connected to IMS network 100, which is the“home” IMS network of terminal A and therefore handles the session forterminal A. Another similar IMS network 104 handles the session forterminal B. Basically, multimedia services are handled by the terminal'shome IMS network even when roaming in a visited access network. In theshown example, terminals A and B belong to different IMS networks 100and 104, respectively, although they may of course instead belong to thesame IMS network.

The illustrated session is controlled by specific session managing nodes106 in the IMS network 100. These nodes typically include S-CSCF(Serving Call Session Control Function), I-CSCF (Interrogating CallSession Control Function) and P-CSCF (Proxy Call Session ControlFunction), according to the conventional IMS architecture. Brieflydescribed, a P-CSCF node acts as an entry point towards the IMS network100 from access networks, a plurality of S-CSCF nodes are assigned toactive terminals for managing their sessions using SIP signalling, andan I-CSCF node acts as a gateway for SIP messages from other IMSnetworks.

The IMS network 100 also includes one or more application servers 108for various multimedia services, and a main database node HSS (HomeSubscriber Server) 110 containing subscriber and authentication data.The various functions of the shown network elements 106-110 aregenerally known in the art, not necessary to describe here further tounderstand the context of the present invention.

In the figure, the thick two-way arrow illustrates the communication ofpayload data or “media” between the two terminals A and B, and the thintwo-way arrow illustrates the communication of various control messagesbetween the two IMS networks 100 and 104, typically according to SIP.Each application server 108 supports one or more specific multimediaservices such as “Instant Messaging” (IM), “Push-to-talk over Cellular”(PoC) and “Presence”, where SIP signalling is used to control sessions.In particular, presence services basically make data related to anobserved client available to other watching clients.

In this description, the term “presence data”, or generally “clientdata”, is used to represent information on the state or situation of aclient and his/her equipment in any predefined respect. Brieflydescribed, presence data of a client is published by storage at anapplication server generally referred to as a “presence server”, whichcan be supplied to other clients subscribing to that presence data. Thepresence data may refer to the following exemplary client states:

-   A personal status, e.g. available, busy, in a meeting, on holiday,    etc.-   A terminal status, e.g. switched on/off, engaged, out of coverage,    etc.-   The geographic location of the client/terminal.-   Terminal capabilities, e.g. functionality for SMS, MMS, chat, IM,    video, etc.-   Terminal selections, e.g. call forwarding, language, etc.-   Other client information, e.g. interests, occupations, personal    characteristics, moods, personal logos, logo depending on the    current mood, etc.

This type of information is continually stored in presence servers inthe IMS network, based on publications of so-called “client events”received from clients or their access networks, whenever any presencedata for a client is introduced, updated, changed or deleted. A clientmay thus also subscribe for selected presence data of one or more otherclients which is also handled by an application server in the IMSnetwork.

In this description, the term “client” will be used to generallyrepresent a user equipment (or terminal) and its user. Further, the term“watching client” represents a client that subscribes or requests forpresence data (sometimes also referred to as the “Watcher”), and theterm “observed client” represents a client that publishes presence data(sometimes also referred to as the “Presentity”) to be available forobservation by authorised watching clients.

A SIP message called “SIP PUBLISH” is generally used by observed clientsto send their presence data to the presence server for publication.Another SIP message called “SIP SUBSCRIBE” is used by watching clientsto subscribe for presence data of observed clients. The SIP PUBLISHmessage can be used basically in four different cases, namely: 1) toinitiate new data, 2) to “refresh” data (i.e. confirming that earlierinitiated data continue to be valid), 3) to modify data, and 4) toterminate data no longer valid. The SIP SUBSCRIBE message can be used toobtain presence data either just once or on a regular basis, asdetermined by a time-out parameter that can be set in that message. Ifthe time-out parameter is set to zero, a notification with requestedpresence data is obtained just once and the subscription is promptlyterminated.

In order to obtain a subscription for presence data of an observedclient, the watching client must be authorised by the observed client toreceive such presence data, which is controlled by means of presencerules dictated for the observed client. A protocol called XCAP (XMLConfiguration Access Protocol) can be used to introduce, modify anddelete presence authorisation rules in a presence rule database.

FIG. 2 illustrates a conventional procedure for obtaining a subscriptionfor presence data, involving the user equipment A of a watching clientand the user equipment B of an observed client belonging to an IMSnetwork 200 comprising a presence server 202 acting for client B. Theshown procedure is valid for a standard presence solution defined byOMA-PAG, based on various standards according to 3GPP and IETF-SIMPLE.As shown in the figure, clients A and B are represented by mobileterminals operated by users, even though the described procedure can beapplied for fixed terminals as well. It is assumed that client A isinitially unauthorised to receive presence data of client B.

A first step 2:1 a generally illustrates that the observed client Bpublishes presence data by sending SIP PUBLISH messages to presenceserver 202 according to conventional routines, as described above.Certain data for client B can also be sent from client B's accessnetwork, e.g. location and terminal status data. The presence data forclient B is maintained in a presence database 204, and step 2:1 billustrates that database 204 is updated accordingly in response toreceiving the SIP PUBLISH messages of step 2:1 a. Steps 2:1 a and 2:1 bcontinue throughout in the background, according to prevailing routines.

Client A now wants to obtain presence data of client B, but must beauthorised to receive such data. Thus, a standard SIP SUBSCRIBE messageis sent to the presence server 202 in a step 2:2, as a request forpresence data of client B, which can be expressed as “SUBSCRIBE (Eventpackage=presence, B)”.

Upon receiving the SIP SUBSCRIBE message, the presence server 202determines whether client A is authorised to receive data or not, bychecking presence rules in a database 206, in a following step 2:3. Ifthe rules in database 206 dictate that client A is “allowed”, a SIPNOTIFY is sent to the watching client A with current presenceinformation of the observed client B, but if client A is found to be“blocked”, the subscription attempt is rejected. In this example, it isassumed that the presence rule database 206 contains no authorisationdecision for client A, and the presence server may then be configured tosend a reject message or simply ignore the request.

Another alternative currently developed, and being illustrated here, isthat client B has earlier sent a subscription request (not shown) topresence server 202 for information on any attempts of unauthorisedclients to get presence data, which can be expressed as “SUBSCRIBE(Event package=presence.winfo, B)”. The presence server 202 thusnotifies client B that client A has made a subscription attempt, bysending a SIP NOTIFY message to client B, in a next step 2:4, which canbe expressed as “NOTIFY (Event package=presence.winfo, A)”. Receivingthe notification, client B can then decide whether client A should beauthorised to receive the requested presence data or not, or optionallyonly selected parts thereof, by means of a suitable terminal inputcommand as indicated in a step 2:5.

Next, client B responds to the notification of step 2:4 by sending anauthorisation decision for client A to the presence server 202, in afollowing step 2:6, which may be sent in an XCAP PUT message. Theauthorisation decision could be any of: allow, reject, polite block,etc., which is stored as an authorisation rule in the presence ruledatabase 206, in a step 2:7. If client B just ignores the message ofstep 2:4, the request would be naturally rejected.

In this example, client B actually allows client A to receive his/herpresence data. The presence server 202 therefore finally sends an SIPNOTIFY message containing valid presence data of client B to client A,in a step 2:8, which can be expressed as “NOTIFY (Eventpackage=presence, B)”.

By notifying client B on the subscription attempt of client A, asubscription for presence data can be easily established by sending theinitial standard SIP SUBSCRIBE message of step 2:2 above, provided thatclient B allows the subscription. However, the SIP NOTIFY message ofstep 2:4 to client B identifies the attempting client A only by a nameor network address derived from the SIP SUBSCRIBE message of step 2:2,which the receiving user may not be able to recognise or understand. Forexample, if an identity of client A is given in the message thatindicates a name, e.g. in the manner of “bengt.larsson@telia.com”,client B may possibly recognise it, if known, but not that easily if theidentity is given in the manner of “user1224@freeweb.com” or the like.

In order to overcome this limitation, client A can always contact clientB separately to identify himself/herself and ask for permission, e.g. bymeans of a phone call, SMS, e-mail or other messaging mechanism.However, this additional communication would increase the network loadand entail extra efforts and costs for the clients involved. Further,the observed client may not have the same type of messaging clientcapabilities or may be otherwise incompatible. Client B may also applyaccess restrictions to incoming messages allowing messages from knownclients only, thereby preventing client A to communicate in this way ifunknown.

SUMMARY

The object of the present invention is to address the problems outlinedabove. In particular, it is an object of the present invention toprovide a solution that avoids the need for additional calls ormessaging when trying to obtain presence information on an observedclient. These objects and others may be obtained by using a method andarrangement according to the attached independent claims.

According to one aspect, the present invention provides a method ofhandling a request for client data of an observed client, as executed ina client data server capable of providing client data of the observedclient to authorised watching clients. A subscription request has beenreceived from the observed client for notifications on any unauthorisedattempts to get client data. In this method, an expanded request forclient data of the observed client is received from an initiallyunauthorised watching client, where the expanded client data requestcontains additional information that has been created or selected by thewatching client to identify or present himself/herself in the clientdata request. After detecting that the watching client is unauthorised,the additional information is extracted from the expanded client datarequest, and an expanded notification is sent to the observed client onthe unauthorised attempt of the watching client to get client data,where the expanded notification containing the extracted additionalinformation.

The additional information may include a text string, a picture, avideo/audio clip, or a link to a personal home page or to a downloadablefile.

In response to the expanded notification, an authorisation decision maybe received from the observed client that may include an additionalmessage from the observed client which is then sent together with therequested client data in an expanded client data notification to thewatching client. Alternatively, an additional message receivedseparately from the observed client can be sent together with therequested client data in an expanded client data notification to thewatching client.

The received expanded client data request may be a request for clientdata according to a list of plural observed clients, and may includeeither unique pieces of additional information valid for each observedclient in the list, or a global piece of additional information validfor all observed clients in the list.

According to another aspect, the present invention provides anarrangement in a client data server for handling a request for clientdata of an observed client according to the client data server methodabove. The inventive client data server arrangement comprises acommunication unit and a logic unit. The communication unit is adaptedto receive an expanded request for client data of the observed clientfrom an initially unauthorised watching client, where the expandedclient data request contains additional information that has beencreated or selected by the watching client to identify or presenthimself/herself in the client data request. The logic unit is adapted toextract the additional information from the expanded client data requestafter detecting that the watching client is unauthorised. Thecommunication unit is further adapted to send an expanded notificationto the observed client on the unauthorised attempt of the watchingclient to get client data, containing the extracted additionalinformation.

According to yet another aspect, the present invention provides a methodof requesting for client data of an observed client, as executed in auser equipment of an initially unauthorised watching client. In thewatching client method, an expanded request for client data of theobserved client is created containing additional information that hasbeen created or selected by the watching client to identify or presenthimself/herself in the client data request. The expanded client datarequest is then sent to a client data server capable of providing clientdata of the observed client to authorised watching clients.

As mentioned above, the expanded client data request may be a requestfor client data according to a list of plural observed clients, and theexpanded client data request may include unique pieces of additionalinformation for each client in the list or a global piece of additionalinformation for all clients in the list.

According to yet another aspect, the present invention provides anarrangement in a user equipment of an initially unauthorised watchingclient, for making a request for client data of an observed clientaccording to the user equipment method above. The inventive userequipment arrangement comprises a logic unit and a communication unit.The logic unit is adapted to create an expanded request for client dataof the observed client, containing additional information that has beencreated or selected by the watching client to identify or presenthimself/herself in the client data request. The communication unit isadapted to send the expanded client data request to a client data servercapable of providing client data of the observed client to authorisedwatching clients.

According to yet another aspect, the present invention also provides amethod of handling a request for client data from an initiallyunauthorised watching client as executed in a user equipment of anobserved client. In the observed client method, a subscription requestfor notifications on any unauthorised attempts to get client data issent to a client data server capable of providing client data of theobserved client to authorised watching clients. At some point later, anexpanded notification on a client data request of the watching client isreceived from the client data server, containing additional informationthat has been created or selected by the watching client to identify orpresent himself/herself in the client data request. The additionalinformation is then extracted from the expanded notification andpresented to the observed client user.

According to a further aspect, the present invention also provides anarrangement in a user equipment of an observed client for handling arequest for client data from an initially unauthorised watching client,comprising a communication unit, a logic unit, and a presenting unit.The communication unit is adapted to send a subscription request fornotifications on any unauthorised attempts to get client data, to aclient data server capable of providing client data of the observedclient to authorised watching clients. The communication unit is furtheradapted to receive an expanded notification on a client data request ofthe watching client from the client data server, containing additionalinformation that has been created or selected by the watching client toidentify or present himself/herself in the client data request. Thelogic unit is adapted to extract the additional information from theexpanded notification, and the presenting unit is adapted to present theextracted additional information.

The present invention enables the user at the observed client to take anauthorisation decision for the watching client, considering thepresented additional information. Thereby, it is possible to identifyand assess an unauthorised watching client more easily, as compared tothe prior art. The present invention can be implemented by usingexisting standard mechanisms without seriously impacting the trafficload nor requiring any extra network resources.

Further features of the present invention and its benefits can beunderstood from the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by means ofexemplary embodiments and with reference to the accompanying drawings,in which:

FIG. 1 is a schematic overview of a basic communication scenarioinvolving two terminals and an IMS network, according to the prior art.

FIG. 2 is a block diagram illustrating a conventional procedure forobtaining presence data of an observed client, according to the priorart.

FIG. 3 is a block diagram illustrating a procedure for obtaining andproviding presence data of an observed client, according to oneembodiment.

FIG. 4 is a flow chart with steps in a procedure executed by a clientdata server for handling a request for client data of an observedclient, according to another embodiment.

FIG. 5 is a flow chart with steps in a procedure executed by a userequipment of a watching client for obtaining client data of an observedclient, according to yet another embodiment.

FIG. 6 is a flow chart with steps in a procedure executed by a userequipment of an observed client for handling a request from a watchingclient for client data, according to yet another embodiment.

FIG. 7 is a block diagram illustrating a user equipment of a watchingclient, a user equipment of an observed client, and a client data servercapable of providing client data of the observed client, according tofurther embodiments.

DETAILED DESCRIPTION

Briefly described, the present invention can be used for conveyingadditional information, such as a personal message or the like, to anobserved client when requesting for presence information or client data,without requiring any additional communication for calls or messaging. Arequesting client can include the additional information in an“expanded” request for client data of an observed client, e.g. as an SIPSUBSCRIBE message, which is sent to a client data server capable ofsupplying the requested client data.

The additional information may be a freely composed text string, suchas: “Hi, this is Bob. We met at the pub last night”. The additionalinformation may also include any other information element created orselected by the requesting client, such as a picture, a video/audioclip, or a link to a personal home page or to a downloadable file. Thus,the client is free to select any piece of description, identification orother object to make up the additional information in the client datarequest.

When the client data server receives the expanded client data request,the additional information therein is detected and extracted forinsertion in a likewise “expanded” client data request notification,e.g. an SIP NOTIFY message, which is sent to the observed client. Theuser equipment (or terminal) of the observed client then presents theadditional information such that the user can take an authorisationdecision for the requesting client, considering the presented additionalinformation.

Thus, the user will then be able to identify and assess the requestingclient more easily, as compared to receiving only a name or a networkaddress in a regular notification. Moreover, no extra communication isneeded to convey the additional information.

The term “presence data” will be used here to represent any client datathat is made available, or “observed”, according to the mechanismsdescribed below. Further, the described “client data server” may be anyserver or functional entity capable of supplying client data of observedclients to watching clients, which could also be termed a “notifier” orthe like.

Even though the following embodiments are generally described in termsof presence services, the invention is not limited thereto but can beimplemented for any applications and services using the client datasubscribe mechanism. Further, the presence server described below couldbe any server capable of providing requested client data to authorisedwatching clients.

In the following description, reference will be made to well-known SIPmessages although the present invention is generally not limitedthereto. An embodiment will now be described with reference to asignalling procedure in a block diagram shown in FIG. 3, using the samenumerals as in FIG. 2 for a requesting/watching client A, an observedclient B, a presence server 202, a presence database 204, and a ruledatabase 206.

The ongoing routine of maintaining updated presence data for client B,as shown by steps 2:1 a and 2:1 b in FIG. 2, is not shown here forsimplicity. In a first step 3:1, client B sends a subscription requestto presence server 202 for information on any attempts of unauthorisedclients to get presence data, which can be expressed as “SUBSCRIBE(Event package=presence.winfo, B)”.

A next step 3:2 illustrates that the user of client A creates anexpanded request for presence data of client B by including additionalinformation in the presence data request. If SIP signalling is used, itis only required that the additional information can be accommodated inan SIP SUBSCRIBE message, either in an existing header, in a new header,or as a part of the message body. The additional information may containany message or description as exemplified above. The expanded presencedata request 300 with the additional information 300 a is then sent tothe presence server 202, in a following step 3:3.

Upon receiving the presence data request 300, the presence server 202checks in the presence rule database 206 whether the requesting client Ais authorised to receive the requested data or not, in a step 3:4, andfinds no authorisation decision in the presence rule database 206 forclient A, thus being unauthorised. In accordance with the subscriptionrequest for information on unauthorised attempts to get presence datareceived in step 3:1, the presence server 202 is thus obliged to reportthe attempt of client A to client B.

Before reporting, presence server 202 extracts the additionalinformation 300 a from the received presence data request 300, asschematically illustrated in a further step 3:5. The presence server 202then sends an expanded presence request notification 302 including theadditional information 300 a to client B, in a next step 3:6, which canbe expressed as “NOTIFY (Event package=presence.winfo, A)”. Again, ifSIP signalling is used, it is only required that the additionalinformation 300 a can be accommodated in an SIP NOTIFY message, eitherin an existing header, in a new header, or as a part of the messagebody.

The user equipment (or terminal) of client B then presents theadditional information 300 a accordingly, in a further step 3:7, e.g. bydisplaying a text string, a picture, or a URL pointing to a home page ordownloadable file, or by playing an audio message, etc. The user canthen decide whether to authorise the requesting client A or not,considering the presented additional information. In this way, theobserved client can hopefully identify and assess the requesting clientmore easily, as compared to receiving just a client identity that maynot be recognised.

Client B is now free to respond to the presence request notification 302by sending an authorisation decision 304 to presence server 202, in afollowing step 3:8. Optionally, client B may also insert an additionalmessage 304 a in the authorisation decision 304, to be sent to thewatching client A in an expanded presence notification. Client B couldalso predefine certain standard messages for different categories ofwatchers (such as pending, allowed, blocked, polite blocked etc.), whichcan be automatically included in the authorisation decision 304depending on the decision outcome.

Similar to step 2:6 described above, the authorisation decision 304 ofstep 3:8 may be sent in an XCAP PUT message, as any of: allow, reject,polite block, etc., which is normally used for changing presenceauthorisation rules. Once received by the presence server 202, theauthorisation decision is stored as a rule in the presence rule database206, in a step 3:9. If client B just ignores to respond to the presencerequest notification 302, client A will of course not be authorisedalthough the request may remain until terminated by client A.

Accordingly, a rule may then also be introduced in database 206 markingclient A as “ignored” or “rejected”. In this example, however, client Bhas allowed client A to receive the requested presence data, which isretrieved from the presence database 204 in a further step 3:10.

Thereafter, the presence notification 306 is finally sent to client A ina step 3:11, containing valid presence data of client B and optionallyalso the added message 304 a, which can be expressed as “NOTIFY (Eventpackage=presence, B)”. Again, if SIP signalling is used, it is onlyrequired that the optional additional message 304 a can be accommodatedin an expanded SIP NOTIFY message, either in an existing header, in anew header, or as a part of the message body. The step of extracting theadditional message 304 a from the authorisation decision 304 beforesending it together with the presence notification 306 is not shown herefor simplicity.

Another alternative would be that client B sends a separate SIP Messagewithin the ongoing signalling dialogue, to convey a personal message toclient A. Client B would then send the authorisation decision in aregular XCAP message allowing client A to watch presence data of clientB, and also send the separate SIP Message containing the personalmessage to the presence server 202. When receiving the “allow” XCAPmessage, the presence server 202 will take the personal message in theSIP Message and include it in the presence notification 306 to client A.

A procedure for handling a request for presence data of an observedclient according to another embodiment, will now be described withreference to the flow chart shown in FIG. 4. The described procedure isgenerally executed in a client data server capable of providing clientdata of observed clients to authorised watching clients, which may be apresence server or the like as in the example above. In a first step400, a subscription request is received from an observed client fornotifications on any unauthorised attempts to get client data of theobserved client (basically corresponding to step 3:1 in FIG. 3). It isassumed that the client data server stores data of the observed client,that can be supplied to any authorised watching client upon request.

At some point thereafter, a request for client data of the observedclient is received from a watching client in a next step 402 (basicallycorresponding to step 3:3 in FIG. 3). In a step 404, it is then checkedin a rule database or the like whether the watching client is authorisedto receive such client data of the observed client (basicallycorresponding to step 3:4 in FIG. 3).

At this point, three different outcome results are basically possible instep 404: Firstly, if the watching client is found to be authorised(Yes), valid client data is sent to the watching client in a regularnotification in a step 406 a. Secondly, if the watching client isregistered in the rule database as unauthorised (No), the client datarequest is rejected in a step 406 b, which may entail a suitablerejection message to the watching client.

Thirdly, if no authorisation decision whatsoever is found in the ruledatabase for the watching client (No decision), it is checked in afurther step 408 whether any additional information is included in theclient data request received in step 402. If not, a regular notificationfor the unauthorised attempt is sent to the observed client in a nextstep 410 (basically corresponding to step 2:4 in FIG. 2), thus onlyincluding an address or name of the watching client as normally given inthe regular client data request, which may well be unrecognised by theobserved client when received.

However, if additional information is indeed found in the client datarequest received in step 402, e.g. a text string, a link to a homepage,etc., the additional information is extracted from the request in afurther step 412, (basically corresponding to step 3:5 in FIG. 3) forinclusion in a notification for the unauthorised attempt. Finally, theexpanded attempt notification including the additional information issent to the observed client in a last illustrated step 414 (basicallycorresponding to step 3:6 in FIG. 3). Thereby, the observed client canregard the additional information to identify and assess the requestingclient.

As similar to FIG. 3, the procedure may continue from there as theobserved client responds to the expanded attempt notification of step414, according to various alternatives and options, e.g., depending onhow the observed client responds, if at all.

FIG. 5 is a flow chart with steps in a basic procedure executed by auser equipment of a watching client for obtaining client data of anobserved client, according to yet another embodiment. In a first step500, an expanded request for client data of the observed client iscreated including additional information, in response to a user inputcommand for obtaining the client data. The additional information hasbeen created or selected by the watching client, e.g. to identify orpresent himself/herself to the observed client in the client datarequest.

In a next step 502, the created client data request is sent to a clientdata server adapted to provide client data of the observed client to anyauthorised watching client, which may be a presence server or the like.Finally, the requested client data or a rejection is received in a step504 from the client data server, in response to the client data requestsent in step 502. Thus, the requested client data is received if theobserved client has decided to authorise the watching client, but ifnot, a rejection is received.

FIG. 6 is a flow chart with steps in a basic procedure executed by auser equipment of an observed client for handling a request from awatching client for client data, according to yet another embodiment. Ina first step 600, a subscription request for information on any attemptsof unauthorised clients to get client data, is sent (in response to auser command) to a client data server adapted to provide client data ofthe observed client to authorised watching clients. As in theembodiments described above, the client data server may be a presenceserver or the like.

In a next step 602, an expanded notification on a client data request ofa watching client is received at some point, the notification containingadditional information that has been included in the client data requestby the watching client.

Finally, the additional information is extracted from the expandednotification of an observed client and presented by the user equipment,in a step 604. The additional information extracted from the expandedclient data request notification may be presented visually and/oraudibly, depending on the format.

FIG. 7 is a block diagram illustrating a user equipment 700 of aninitially unauthorised watching client A, a user equipment 702 of anobserved client B, and a client data server 704 capable of providingclient data of the observed client, according to further embodiments.

The user equipment 700 of the watching client A includes an arrangementfor requesting for client data of the observed client B, basicallycomprising a user input unit 700 a, a logic unit 700 b and acommunication unit 700 c. The user input unit 700 a is used forreceiving user input commands for creating a client data request.

The logic unit 700 b is adapted to create an expanded request for clientdata of the observed client, in response to a user input commandreceived by the user input unit 700 a. The expanded request containsadditional information that has been created or selected by the watchingclient to identify or present himself/herself in the client datarequest. The communication unit 702 c is adapted to send the expandedclient data request R to the client data server 704.

The client data server 704 includes an arrangement for handling requestsfor client data when a subscription request has been received from theobserved client for notifications on any unauthorised attempts to getclient data, basically comprising a logic unit 704 a and a communicationunit 704 b.

The communication unit 704 b is adapted to receive the expanded clientdata request R from the watching client A. The logic unit 704 a isadapted to extract the additional information from the expanded clientdata request, after detecting that the watching client is unauthorisedby checking a rule database 706 for the observed client B. Thecommunication unit 704 b is further adapted to send an expandednotification N to the observed client on the unauthorised attempt of thewatching client to get client data, said expanded notificationcontaining the extracted additional information.

The user equipment 702 of the observed client B includes an arrangementfor handling the request for client data from the watching client A,basically comprising a presenting unit 702 a, a logic unit 702 b, and acommunication unit 702 c.

The communication unit 702 c is adapted to send a subscription request Sto the client data server 704 for notifications on any unauthorisedattempts to get client data, and to receive an expanded notification Non a client data request of the watching client, said expandednotification containing additional information that has been created orselected by the watching client to identify or present himself/herselfin the client data request. The logic unit 702 b is adapted to extractthe additional information from the expanded notification, and thepresenting unit 702 a is adapted to present the extracted additionalinformation.

If the observed client B decides to authorise the watching client toreceive the requested client data, the logic unit 704 a can retrieveclient data from a client database 708, and the communication unit 704 bcan send the retrieved client data to the watching client A.

It should be noted that the different elements in the nodes 700, 702 and704 shown in FIG. 7 are described in terms of their logic functions,which can be implemented by the skilled person by means of varioushardware and software in any suitable manner.

The present invention can also be used when a watching client subscribesor requests for client data according to a list of plural observedclients, wherein the same notification mechanism for client datainformation is used. However, a list subscription is different since thesame subscription is used for multiple observed clients. Client data maythen be obtained from plural client data servers associated withrespective observed clients in the list.

A list subscription can be created “ad-hoc”, i.e. a list of clients isincluded in the body of the subscription request. Alternatively, a listsubscription can be created based on a pre-defined list of clients,which can be stored in an XCAP server and retrieved by the client dataserver when a list identifier is included in the client data request.

In both cases, it is possible to specify in the client data requesteither unique pieces of additional information to each observed client,or a global piece of additional information valid for all observedclients in the list. This can be done by including the additionalinformation in the request either in an existing header, or as anadditional header, or as a part of the request message body as in thecase of individual client data requests as described above.

If the additional information is unique per client, different pieces ofadditional information must be included in the request where each pieceof additional information points to a specific observed client. In thecase of pre-defined pieces of additional information, they can becreated once and stored in the XCAP server. A so-called Resource Listserver (RLS) can then be used for extracting the different pieces ofadditional information from the client data request, to include it in aclient data request or presence subscription towards each presenceserver of the respective clients. Each presence server will then use themechanism provided by means of the present invention. Moreover, if aglobal message is used, it can be created once and used for any newobserved clients that may be added to the list.

By presenting the additional information at the observed client, itbecomes possible to identify and assess the requesting client moreeasily, as compared to using only a name or a network address in aregular notification according to the prior art. Thus, the user at theobserved client can take an authorisation decision for the watchingclient, considering the presented additional information.

Further, the present invention can be implemented by using existingstandard mechanisms without seriously impacting the traffic load norrequiring any extra network resources. As described above, the presentinvention can be used when subscribing to individual observed clients aswell as to lists of plural observed clients. By incorporating theadditional information in the client data request or presence request,it is not necessary to coordinate any separate messaging in the solutionfor achieving this functionality.

While the invention has been described with reference to specificexemplary embodiments, the description is generally only intended toillustrate the inventive concept and should not be taken as limiting thescope of the invention, which is defined by the appended claims. The IMStechnology and the SIP signalling protocol have been frequently usedwhen describing the above embodiments, although any other standards andprotocols for enabling the above-described functions and services maybasically be used.

1-28. (canceled)
 29. A method of handling a request for client data of an observed client, as executed in a client data server that provides client data of the observed client to authorized watching clients, wherein a subscription request has been received from the observed client for notifications on any unauthorized attempts to get client data, the method comprising the steps of: receiving an expanded request for client data of the observed client from an initially unauthorized watching client, the expanded client data request containing additional information that has been created or selected by the watching client to identify the watching client in the expanded client data request; detecting that the watching client is unauthorized; extracting the additional information from the expanded client data request after detecting that the watching client is unauthorized; and sending an expanded notification to the observed client regarding the unauthorized attempt of the watching client to get client data, the expanded notification containing the extracted additional information.
 30. The method according to claim 29, wherein the detecting step includes detecting that the watching client is unauthorized by checking a rule database for the observed client.
 31. The method according to claim 29, further comprising receiving an authorization decision from the observed client in response to the expanded notification.
 32. The method according to claim 31, wherein the received authorization decision authorizes the watching client to receive the requested client data and includes an additional message from the observed client, and the method further comprises sending the additional message together with the requested client data in an expanded client data notification to the watching client.
 33. The method according to claim 31, wherein the received authorization decision authorizes the watching client to receive the requested client data, and the method further comprises receiving an additional message separately from the observed client, wherein the server sends the additional message together with the requested client data in an expanded client data notification to the watching client.
 34. The method according to claim 29, wherein the client data server is a presence server, the expanded client data request is an SIP SUBSCRIBE message accommodating the additional information either in an existing header, in a new header, or as a part of the message body, and the expanded notification on the unauthorized attempt is an SIP NOTIFY message accommodating the additional information either in an existing header, in a new header, or as a part of the message body.
 35. The method according to claim 29, wherein the additional information includes any of: a text string, a picture, a video/audio clip, a link to a personal home page, and a link detecting that the watching client is unauthorized to a downloadable file.
 36. The method according to claim 29, wherein the received expanded client data request is a request for client data according to a list of a plurality of observed clients.
 37. The method according to claim 36, wherein the list is an ad-hoc list or a predefined list of observed clients indicated by a list identifier included in the client data request, wherein the predefined list is stored in an XCAP server and retrieved by the client data server using a list identifier included in the expanded client data request.
 38. The method according to claim 36, wherein the received expanded client data request includes either unique pieces of additional information valid for each observed client in the list, or a global piece of additional information valid for all observed clients in the list.
 39. An arrangement in a client data server for handling a request for client data of an observed client, the arrangement providing client data of the observed client to authorized watching clients, wherein a subscription request has been received from the observed client for notifications on any unauthorized attempts to get client data, the arrangement comprising: a communication unit; and a logic unit in communication with the communication unit; wherein: the communication unit includes means for receiving an expanded request for client data of the observed client from an initially unauthorized watching client, the expanded client data request containing additional information that has been created or selected by the watching client to identify the watching client in the client data request; the logic unit includes means for detecting that the watching client is unauthorized and for extracting the additional information from the expanded client data request after detecting that the watching client is unauthorized; and the communication unit further includes means for sending an expanded notification to the observed client regarding the unauthorized attempt of the watching client to get client data, the expanded notification containing the extracted additional information.
 40. The arrangement according to claim 39, wherein the means for detecting that the watching client is unauthorized includes means for checking a rule database for the observed client.
 41. The arrangement according to claim 39, wherein the communication unit includes means for receiving an authorization decision from the observed client in response to the expanded notification.
 42. The arrangement according to claim 41, wherein the received authorization decision authorizes the watching client to receive the requested client data and includes an additional message from the observed client, and wherein the communication unit sends the additional message together with the requested client data in an expanded client data notification to the watching client.
 43. The arrangement according to claim 42, wherein the received authorization decision authorizes the watching client to receive the requested client data, and wherein the communication unit receives an additional message separately from the observed client, and sends the additional message together with the requested client data in an expanded client data notification to the watching client.
 44. The arrangement according to claim 39, wherein the client data server is a presence server, the expanded request for client data is an SIP SUBSCRIBE message accommodating the additional information either in an existing header, in a new header, or as a part of the message body, and the expanded notification on the unauthorized attempt is an SIP NOTIFY message accommodating the additional information either in an existing header, in a new header, or as a part of the message body.
 45. The arrangement according to claim 39, wherein the additional information includes any of: a text string, a picture, a video/audio clip, a link to a personal home page, and a link to a downloadable file.
 46. A method of requesting client data of an observed client, as executed in a user equipment of an initially unauthorized watching client, the method comprising the steps of: creating or selecting identifying information to identify the watching client; creating an expanded request for client data of the observed client, the expanded request containing the identifying information; and sending the expanded client data request to a client data server that provides client data of the observed client to authorized watching clients.
 47. The method according to claim 46, wherein the created expanded client data request is an SIP SUBSCRIBE message accommodating the additional information either in an existing header, in a new header, or as a part of the message body.
 48. The method according to claim 46, wherein the expanded client data request is a request for client data according to a list of a plurality of observed clients.
 49. The method according to claim 48, wherein the list is an ad-hoc list or a predefined list of observed clients indicated by a list identifier included in the client data request, wherein the predefined list is stored in an XCAP server and retrieved by the client data server using a list identifier included in the client data request.
 50. The method according to claim 48, wherein the expanded client data request includes either unique pieces of additional information valid for each observed client in the list, or a global piece of additional information valid for all observed clients in the list.
 51. An arrangement in a user equipment of an initially unauthorized watching client, for making a request for client data of an observed client, the arrangement comprising: a communication unit; and a logic unit in communication with the communication unit; wherein: the logic unit includes means for creating an expanded request for client data of the observed client, the expanded request containing additional information that has been created or selected by the watching client to identify the watching client in the client data request; and the communication unit includes means for sending the expanded client data request to a client data server that provides client data of the observed client to authorized watching clients.
 53. A method of handling a request for client data from an initially unauthorized watching client, as executed in a user equipment of an observed client, the method comprising the steps of: sending a subscription request for notifications on any unauthorized attempts to get client data, to a client data server that provides client data of the observed client to authorized watching clients; receiving from the client data server, an expanded notification regarding a client data request by the watching client, the expanded notification containing additional information for identifying the watching client in the client data request; extracting the additional information from the expanded notification, and presenting the extracted additional information to a user of the observed client.
 53. The method according to claim 52, wherein the received expanded notification is an SIP NOTIFY message accommodating the additional information either in an existing header, in a new header, or as a part of the message body.
 54. The method according to claim 52, further comprising sending an authorization decision message to the client data server authorizing the watching client to receive the requested client data upon receiving an indication from the user that the watching client is authorized, the authorization decision message including an additional message to the watching client from the observed client.
 55. The method according to claim 52, further comprising: sending an authorization decision message to the client data server authorizing the watching client to receive the requested client data upon receiving an indication from the user that the watching client is authorized; and separately sending to the client data server, an additional message for the watching client.
 56. An arrangement in a user equipment of an observed client, for handling a request for client data from an initially unauthorized watching client, the arrangement comprising: a communication unit; a presenting unit; and a logic unit in communication with the communication unit and the presenting unit; wherein: the communication unit includes: means for sending a subscription request for notifications on any unauthorized attempts to get client data, to a client data server that provides client data of the observed client to authorized watching clients; and means for receiving from the client data server, an expanded notification regarding a client data request by the watching client, the expanded notification containing additional information for identifying the watching client in the client data request; the logic unit includes means for extracting the additional information from the expanded notification; and the presenting unit includes means for presenting the extracted additional information to a user of the observed client. 